CVE-2013-0640的分析记录

概述

在Adobe Reader的XFA（XML Forms Architecture）处理模块AcroForm.api 中，存在一个用于得到任意代码执行权限的漏洞，编号为CVE-2013-0640。另一个是 CVE-2013-0641，该漏洞存在于 Adobe sandbox 的 broker 进程中，用于从sandbox 中逃逸，获取高权限，这两个漏洞同时被用在了一个样本中。CVE-2013-0640的POC可在古河的文章下获取（ https://bbs.pediy.com/thread-163035.htm ）。

实验环境

版本为11.0.1的Aodbe Reader，XPSP3，Win7，OD，windbg，IDA

漏洞触发原因

漏洞触发的基本过程是这样：AcroForm.api中的内存分配函数Alloc在分配 Adobe Reader的 XML表单中的新节点NewObject后，由一个存在缺陷的函数bugFun来调用这个新节点，一开始分配的时候 NewObject 的大小为40h字节，但是当缺陷函数bugFun再去引用这个节点NewObject的时候，访问的却是[NewObject+44h]的地方，多访问了4个字节，而这个位置也是一个对象的指针，这个漏洞的产生原因就是bugF函数在引用节点NewObject的时候没有对可引用的范围做限制，造成了越界访问。

分析记录

这里先是分析了CVE-2013-0640的POC样本，这个POC用来演示CVE-2013-0640的触发和利用，之后再分析了真实样本。 

首先将OD设置为实时调试器，接着打开POC，不久OD就会捕获异常，程序停在了“0x88888888”，由于这个函数地址＂0x88888888＂是伪造的，也是不存在的，于是函数没有正常返回，可以看到是“0x208a54d3”调用了函数，在上面的指令中可以看到取函数地址的过程，如下图所示：

接着用windbg来分析，感觉用windbg下断点更方便。用Windbg附加Aodbe Reader后，直接ｇ命令运行，crash的完整汇编代码如下：

对应的伪代码：

可以对比着看上图OD在crash的现场，在”0x208A54b9“的地址处获得了[NewObject+44h]的虚表指针，在这之前esi的值由”0x208A5488“处的mov esi,[eax]赋予，而eax的值最初由”0x208A5478“处的调用函数生成返回，就是这个函数”0x208A5514“生成了新节点NewObject，具体的分配函数是”0x208A5514“的一个子函数：这里可以看到新节点NewObject的大小为４０ｈ，但是上图中”０x208A54b9“处却引用了偏移４４ｈ的位置 ，多访问了四个字节：

而这个 [NewObject+44h]的地址存放的也是某个对象的指针，该对象的结构如下：

 struct NewObject＋４４t {

+0 虚表

+4 referencecount //当引用计数为 0 时，对象将被析构

+30 unknown

+48 MemberArray //一个数组结构的指针 }

重新用windbg附加Adobe Reader，一开始有说到漏洞函数存在的模块为AcroForm.api，于是用模块断点”sxe ld AcroForm.api"对漏洞函数所在的模块下断点，成功之后根据上面的分析在”0x208a54b9“处下下断观察[NewObject+44h]的虚表指针被覆盖的过程：

接着通过内存写断点"ba w4 0c0c0c20"来跟踪虚表地址被覆盖的过程，如下图所示：

样本构造

这部分内容参考古河的分析：https://bbs.pediy.com/thread-163035.htm 

通过以上分析可知，只要能控制[NewObject+44ｈ]处该对象指针的值，以及这个值所指向的内存区域的内容，就能控制 EIP，首先将[NewObject+0x44]处的值设为 0x0c0c0c20,于是 0x0c0c0c20 将被当 成一个 Member44_t 对象的指针进行后续操作，同时我们将 0x0c0c0c20 处的内存布局成如下形式：

1. [0x0c0c0c20] = 0x0c0c0c28, 在析构对象调用析构函数时将被使用。

2. [0x0c0c0c24] = 1，该对象的引用次数，将其设置为 1，于是在 “dec dword ptr [ecx+4]” 的减操作完成后，析构动作立即发生。

3. [0x0c0c0c28] = 0x88888888，这个是虚表中第一个函数，最后 crash 时 EIP 会指向 0x88888888

现在的问题是我们如何精确地控制[NewObject+0x44]处的值，使其变成 0x0c0c0c20? 这个是可以办到的，关键在于 AcroForm.api 中自带的堆内存分配机制。 AcroForm.api 有自己的堆分配管理机制（可选），这个机制和 Windows 自身的很像，它针对大小为 0 ~ 0x100 的内存分配有专门的 0x100 个 freelist，用来保存已经释放的内存块（当然没有真的调用 free 去释放，同时还有另外的一个 freelist 存放其它大小的 已释放内存块。

当一个内存分配请求到来时，先检查 freelist 中有没有合适的内存块，如果找到合适的，则直接返回这个块；如果没有正好合适的大小，则尝试将较大的已释放内存块切成小一点的内存块返回，实在找不到了才会新分配内存。这里还有一个要点是，对于 freelist 中的内存块，在释放和重新分配返回时，不会将原有的内容进行清理。

利用这个自定义的内存分配机制，我们现在可以精确地控制[NewObject+0x44]处的内容了。

首先分配一系列较大的内存块，将这些大内存块填充为 0x0c0c0c20。然后分配一些和 NewObject 大小相同的块，这样做的目的是为了将 freelist 中已有的缓存用完。然后，我们释放所有的大内存块，紧接着触发漏洞。在漏洞触发时，NewObject 被分配，由于大小相同的 freelist 已经被清空，于是它会尝试从我们刚刚释放的某个大内存块中切割出一个 0x40 的小内存块并返回。

换句话说，返回的 NewObject 地址其实是落在我们刚刚释放的某个大内存块中间的。于是在越界访问 NewObject+0x44 时，得到的值是我们一开始在大内存块中填充的值，即 0x0c0c0c20。

整个过程如下图：

控制ｅｉｐ的示意图：

POC中的javascript分析：划线标题

“NewObject"的生成和越界访问“NewObject+44h”的过程可以参考POC样本中的javascript代码来理解，关键代码如下：

第一步：解析获取节点

xfa.resolveNode("xfa[0].form[0].form1[0].#pageSet[0].page1[0].#subform[0].field" + index.toString() + "[0].#ui[0]");

uiListNodes.push(node);

//解析并获取 XFA 表单中的一个UI节点，这个节点就是在汇编代码中“0x208A5478”处生成的节点对象“NewObject”

var node = xfa.resolveNode("xfa[0].form[0].form1[0].#pageSet[0].page1[0].#subform[0].field" + index.toString() + "[0].#ui[0].#choiceList[0]");

 choiceListNodes.push(node);

//解析并获取上面得到的UI节点下面紧邻的choiceList节点，这个节点就是“NewObject+44h”处的那个对象

}

第二步：再次解析引用的时候发生越界访问

var node = xfa.resolveNode("xfa[0].form[0].form1[0].#pageSet[0].page1[0].#subform[0].field0[0].#ui");

//引用之前已获取的节点”NewObject“

if ( node == undefined ) {

return false;//如果引用的节点对象未定义，就返回false，啥事没有

}

try {

node.oneOfChild = choiceListNodes.pop();//否则返回“NewObject+44h”对象的指针(被篡改后的)，由于没有对对象的可引用范围做限制，会发生越界访问；

}

catch (e) {

return false;

}

return true;

对真实样本的分析

之后再分析了完整样本，完整样本的分析是在win7中进行的，其中CVE-2013-0640的触发过程基本与上述分析过程一致，主要的问题就是相关漏洞函数的内存地址发生了变化，但是相对偏移地址是不变的，比如XP下的地址"0x208A54d3"在Win7下就会变为"0x67cd54d3"，相对偏移地址没变。在Win7下尝试下断点的时候，一开始没有成功也是因为忽略了不同系统下内存地址的变化，之后先在xp下用“uf +地址”命令找到指令所在的真实地址，比如，"0x208A54d3"和"0x67cd54d3"的真实地址就是：”AcroForm!PlugInMain+0xa31a5“。

这在不同系统下都是一样的，之后通过真实地址成功下了断点。另外就是上面分析的POC并没有ROP链，POC只是用来crash，真实样本中这个漏洞是被实实在在的利用了。

触发过程跟上面的分析一致，就是地址不一样，对完整样本的分析主要是跟进了CVE-2013-0640触发后过程，通过真实地址”AcroForm!PlugInMain+0xa31a5“下断，可以看到在“0x67cd54d3“的位置调用了伪造的虚函数：

如果直接F10执行，函数就会通过rop加载恶意dll，之后就是利用第二个漏洞CVE-2013-0641完成沙盒逃逸，整个逃离过程全是在第一个漏洞引入的dll中完成：

可到对应目录下找到该DLL及其释放的木马：

接着用windbg重新附加Adobe Reader，让程序继续断在“0x67cd54d3“，这次用F8单步跟进，会发现程序开始执行ROP，其中包括了大量的ret指令和pop等操作：

ROP和加载DLL的shell code间是用NOP指令填充的：

shellcode首先会通过GetTempPathW获得Temp文件夹的路径：

之后在该路径下通过fsopen()函数生成指定文件夹和指定的DLL文件"D.T"，可通过fsopen()函数的参数来查看对应的路径和文件：

接着通过fwrite()函数来写入数据：

最后用fclose()函数结束写入：

写入之后通过loadlibrary来加载该文件：

这个DLL加载完，这个漏洞的使命也达到了，往下就是第二个沙箱逃逸漏洞的触发和利用。

总结

前期分析的时候过于陷入别人的分析思路，没有去独立思考，这样很不好，他人的思路也要辩证地接纳，保持独立思考，要尝试自己去勾勒出漏洞触发和利用的流程。

参考文章

1. http://www.freebuf.com/vuls/33448.html

2. https://bbs.pediy.com/thread-163035.htm

看雪ID： 大晟 

https://bbs.pediy.com/user-790832.htm

本文由看雪论坛大晟原创

转载请注明来自看雪社区

热门技术文章推荐：

戳原文，看看大家都是怎么说的？